BackendTLSPolicy doesn't cover TLSRoutes at this point in time. I think we'd need to discuss an addition to the enhancement.

I think an update to BackendTLSPolicy may be helpful to clarify this, but the intent with this phrasing is just being explicit about where TLSRoute encryption stops:

• in Passthrough mode, TLSRoute is encrypted from the client all the way to the workload (and remains as a non-goal/out-of-scope/undefined for BackendTLSPolicy)
• in Terminate mde, TLSRoute is encrypted from the client to the gateway, and how traffic is passed from the gateway to the backend workload is an implementation detail.

BackendTLSRoute was just mentioned as an example of how the gateway to workload traffic would not necessarily be unencrypted (some mesh-integrated gateways have alternative means of encrypting traffic from an ingress to backend workload), not imply any sort of interoperability or support, and it should be fine to rephrase or remove this mention if it's introducing unnecessary confusion.

+1, maybe we can remove any mention to BackendTLSPolicy right now, and once the TLSRoute is defined we can extend BackendTLSPolicy GEP to support TLSRoute when terminating

+1, we should remove the BackendTLSPolicy for now.

For TLSRoutes, the focus should be on the client-to-gateway connection. The gateway-to-backend connection is a separate concern and is out-of-scope for TLSRoutes, as its configuration can vary based on specific needs.

For example, even with end-to-end client-to-backend TLS (aka TLS Passthrough), a mesh deployment might still choose to re-encrypt internal traffic (see diagram below). TLSRoutes have little to none impact on gateway-to-backend connections.

Everything else is Experimental/Core. Can we add a note that TLS Terminate for TLSRoute is extended (or implementation dependent)? Maybe as an asterisk that is explained under the table.

I missed this comment! But I have added explicitly that this is extended